1. Field of the Invention
The present invention relates to a print control apparatus, a print control method, and a program for implementing the method, and more particularly, to a print control apparatus on which operate an application that handles print settings as a print ticket in XML format and a printer driver that manages the print settings as a print settings structure in binary format, a print control method applied to the print control apparatus, and a program for causing a computer to execute the print control method.
2. Description of the Related Art
In a printing environment in the Microsoft Windows (registered trademark) OS (operating system) developed by Microsoft Inc., a memory block called a “DEVMODE” structure used by Win32 applications serves an important role as print settings designating data. DEVMODE is the structure of designation information used when actually instructing a printer to carry out printing. In the Windows OS, DEVMODE provided by the OS stores the content of setting entered on the properties of a printer driver. DEVMODE is referred to by the printer driver that has been handed print data when generating print instructions to be transmitted to the printer.
FIG. 8 is a diagram showing the overall structure of the DEVMODE structure.
The DEVMODE structure is composed of a memory region that stores information relating to device initialization and a printer environment and is characterized by being composed of two regions, a public portion 301 whose specification is made public and a private portion 302 whose specification is not made public and can be accessed by the printer driver only. Normally, only extremely basic information such as sheet type, sheet orientation, resolution, and the like is written as members in the public portion 301 of the DEVMODE structure, with the remaining majority of the information being written as members in the private portion 302.
FIG. 9 is a diagram showing the structure of the public portion 301 of the DEVMODE structure shown in FIG. 8.
In FIG. 9, the “dmDeviceName” member specifies the name of a device supported by the printer driver.
The “dmSpecVersion” member specifies the version number of the initialization data specification on which the DEVMODE structure is based.
The “dmDriverVersion” member specifies the printer driver version number assigned by the developer of the printer driver.
The “dmSize” member specifies the size, in bytes, of the DEVMODE structure not including a “dmDriverData” member (device-specific information).
The “dmDriverExtra” member contains the number of bytes of private driver data that follow the DEVMODE structure.
The “dmFields” member specifies members that have been initialized out of the remaining members of the DEVMODE structure.
The “dmOrientation” member specifies the orientation of the sheet to be printed upon.
The “dmPaperSize” member specifies the size of the sheet to be printed upon.
The “dmPaperLength” member specifies the length of the sheet to be printed upon.
The “dmPaperWidth” member specifies the width of the sheet to be printed upon.
The “dmScale” member specifies the factor by which the printed output is to be scaled when scaling is carried out.
The “dmCopies” member specifies the number of copies printed if the device supports multiple-page copies.
The “dmDefaultSource” member specifies the paper source.
The “dmPrintQuality” member specifies the printer resolution.
The “dmColor” member switches between color and monochrome on color printers.
The “dmDuplex” member specifies “duplex” or double-sided printing for printers capable of double-sided printing.
The “dmYResolution” member specifies the y-resolution, in dots per inch, of the printer.
The “dmTTOption” member specifies how TrueType (registered trademark) fonts should be printed.
The “dmCollate” member specifies whether collation (i.e., sorting into page order) should be used when printing multiple copies.
The “dmFormName” member specifies the name of the form to be used.
The “dmUnusedPadding” member is used to align the DEVMODE structure to a DWORD boundary.
The “dmBitsPerPel” member specifies the color resolution, in bits per pixel, of the display device.
The “dmPelsWidth” member specifies the width, in pixels, of the visible device surface.
The “dmPelsHeight” member specifies the height, in pixels, of the visible device surface.
The “dmDisplayFlags” member specifies the display mode of the device.
The “dmDisplayFrequency” member specifies the frequency, in hertz, of the display device in a particular mode.
In this way, the public portion 301 of the DEVMODE structure is strictly defined by Microsoft as a header file written in C language. On the other hand, the private portion 302 of the DEVMODE structure that is independently defined by a printer driver developer continues immediately after the public portion 301 in the DEVMODE structure and has a size designated by the “dmDriverExtra” member.
In 2004, the hardware engineering conference “WinHEC 2004” was held by Microsoft in Seattle, USA. At the conference, it was announced that XML-based print settings designating data called a “print ticket” (also referred to in general terms as a “job ticket”) would be used in Microsoft's next generation printing system.
DEVMODE, which is comprised of conventional print settings designating data, is written as a data structure. Since the specification of the private portion 302 that occupies the majority of DEVMODE can be freely decided by respective printer vendors, the content of the private portion 302 differs between vendors and is not made public. Also, since data of DEVMODE is binary data, users cannot understand the settings even if they refer to the content of DEVMODE. The private portion 302 of DEVMODE is characterized by being accessible only to a printer driver and in that a Win32 application including an API (Application Programming Interface) that is independent of the printer driver can use the data of DEVMODE (for example, data related to appliance-specific settings that is normally written in the private portion 302 of DEVMODE, such a stapling position and a face up/down setting for the discharged sheets) by communicating with the printer driver using the independent API. A technique by which an application acquires the data of DEVMODE from a printer driver is disclosed in Japanese Laid-Open Patent Publication (Kokai) No. 2003-091387, for example.
On the other hand, a print ticket that is comprised of print settings designating data with the new format has the following five characteristics: (i) the ticket is written in XML (Extensible Markup Language); (ii) the specification of the ticket is made public; (iii) the ticket is written in text format (i.e., readable by the user); (iv) the ticket cannot be directly accessed by a printer driver; and (v) the ticket can be used from a WinFX application with a new-format API.
As described above, although it is a large step forward for a WinFX application to be able to use a print ticket, this only applies to an application layer and the situation is greatly different on a driver layer. This will now be described with reference to FIG. 10.
FIG. 10 is a diagram showing how print settings designating data of DEVMODE and a print ticket are transferred between the application layer, an OS layer, and the driver layer.
In FIG. 10, a Win32 application on the application layer communicates using DEVMODE with a printer driver 501 via a Win32 API on the OS layer.
On the other hand, a process by which a WinFX application on the application layer communicates using print tickets with the printer driver 501 on the driver layer via a WinFX API on the OS layer is quite complex. That is, according to the Microsoft specification, input and output for the printer driver 501 are limited to DEVMODE. This means that to make the printer driver 501 compatible with print tickets, it is necessary to provide the driver layer with a submodule 502 for converting between print tickets and DEVMODE. Due to the functioning of the submodule 502, even though the printer driver 501 is able to handle only DEVMODE, it is possible to have communication carried out between the printer driver 501 and the WinFX application using in effect print tickets.
As shown in FIG. 10, to maintain compatibility with the specification of the conventional Win32 application, as before the printer driver 501 needs to handle DEVMODE comprised of the print settings designating data that is described in non-public binary format. Since the exchanging of print settings with the Win32 application is carried out using conventional DEVMODE, the printer driver can handle the settings without conversion. However, to exchange print settings with the WinFX application, a conversion process (referred to hereinafter as a “ticket cycle”) between a print ticket and DEVMODE has to be frequently carried out. The ticket cycle has a problem that will now be described with reference to FIG. 11.
FIG. 11 is a diagram showing the ticket cycle executed by the submodule 502. When the WinFX application produces a print ticket, the print ticket is converted to DEVMODE by the submodule 502 and the converted DEVMODE is received by the printer driver. Print settings made via the printer driver UI (User Interface) are managed using DEVMODE. On the other hand, when the print settings are passed over to the WinFX application, the printer driver has the DEVMODE converted to a print ticket by the submodule 502 and the converted print ticket is received by the WinFX application.
For this reason, if the ability of a print ticket to express print settings is lower than the ability of DEVMODE to express such settings, there will be a problem in that part of the information in the DEVMODE print settings designating data will be lost when the DEVMODE of the print settings made via the printer driver UI is converted (T1 in FIG. 11) to a print ticket to be passed over to the WinFX application.
To prevent data from being lost in this way, a method that incorporates DEVMODE into the print ticket is conceivable.
FIG. 12 is a diagram showing one example of a print ticket generated by a printer driver based on Microsoft's Unidrv. In the example in FIG. 12, DEVMODE 700 is incorporated inside the print ticket.
However, preventing the loss of data by incorporating DEVMODE in the print ticket in this way is based on a premise of DEVMODE having a greater ability to express print setting designations than the print ticket. When the print ticket has a greater ability to express print setting designations than DEVMODE, it is not possible to prevent data from being lost.
Also, as described above, it is still necessary for the printer driver 501 to handle the DEVMODE structure in order to maintain compatibility with the specification of conventional Win32 applications. For this reason, there have been a number of problems that inconvenience users, such as (i) the ticket cycle is complex and the processing speed is slow, (ii) there is an increased load for data management since it is necessary to manage both the print ticket and DEVMODE, (iii) in spite of the print ticket being based on XML, desired tags cannot be added easily, and (iv) since the size of DEVMODE is decided at a fixed value during initialization, content cannot be added later to DEVMODE.
Also, conventional Win32 applications are not able to access and directly read and write the private portion of the DEVMODE structure. Thus, as shown in FIG. 13, a printer driver 800 accesses a DEVMODE private portion 803 via a driver expansion interface (I/F) 801 that is uniquely designed for the printer driver 800. FIG. 13 shows the relationship between a Win32 application 802 and the driver expansion interface 801 of the printer driver 800 and the relationship between the driver expansion interface 801 and the DEVMODE private portion 803.
By using the driver expansion interface 801, the Win32 application 802 can access and read and write the DEVMODE private portion 803, and as a result, the Win32 application 802 can set original functions supported by the printer driver 800 (for example, a stapling function). The driver expansion interface 801 used by the Win32 application 802 is implemented in the printer driver 800 according to different methods by respective developers and therefore does not have general-purpose applicability (in other words, the interface 801 is incompatible with other drivers). Since the method of using the driver expansion interface 801 will differ if the type of printer driver 800 changes, components of the Win32 application 802 become extremely complex, thereby increasing the time and effort required by application development.
On the other hand, as shown in FIG. 14, a WinFX application 900 can directly access a print ticket 901 and read and write the print ticket 901 directly without performing access via a print driver. FIG. 14 is a diagram showing the relationship between the WinFX application 900 and the print ticket 901.
In this way, since the WinFX application 900 can directly access the print ticket 901, components of the WinFX application 900 become extremely simple.
However, the conventional Win32 application 802 described above cannot handle the print ticket 901 and can only use the DEVMODE private portion 803. In this case, it is necessary to depend on the driver expansion interface 801 that is uniquely designed for the printer driver 800, which has increased the time and effort required to develop Win32 applications.